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The  purpose  of  this  thesis  project  was  to  analyze  and 
model  by  simulation,  the  local  area  network  interconnection 
backbone  proposed  for  the  information  community  at  HQ,  U.S. 
Array  Europe  and  the  Seventh  Army  located  at  Heidelberg, 
Germany . 

The  results  of  this  project  apply  to  performance  of  the 
proposed  backbone.  However,  an  effort  was  made  to  keep  the 
code  design  modular  so  further  development  and  expansion  of 
the  model  can  proceed  as  the  sponsor  sees  fit. 

I  wish  to  thank  Lieutenant  Colonel  Albert  B.  Garcia,  my 
thesis  advisor,  for  his  assistance  throughout  the  course  of 
this  project.  I  also  thank  Mr.  Raymond  Johnson,  my 
sponsoring  organization  point  of  contact  at  the  Information 
Systems  Engineering  Command  -  Europe,  for  his  patience  and 


help  during  my  site  visit. 


Larry  J.  Shrader 
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Abstr; ct 

This  thesis  project  develops  a  simulation  model  of  the 
proposed  backbone  that  will  interconnect  approximately  16 
existing  local  area  networks  of  the  information  community  at 
HQ,  U.  S.  Army  Europe  and  the  Seventh  Army  in  Heidelberg, 
Germany.  The  objective  is  to  develop  a  computer  simulation 
that  determines  throughput  and  delay  characteristics  of  the 
backbone.  Potential  configuration  problems  that  may  limit 
the  full  utility  of  the  system  are  also  identified  from 
results  of  the  simulation. 

An  existing  telephone  switch  at  the  Campbell  Barracks 
in  Heidelberg  will  be  upgraded  and  interfaced,  by  way  of  a 
9.6K  bits/second  link,  to  a^acket  switch  to  provide  an 
Integrated  Services  Digital  Network  (ISDN)  environment  for 
the  integration  of  data  and  voice  in  one  switching  system. 
The  computer  simulation  model  is  developed  to  analyze  the 
data  portion  of  the  proposed  system  only. 

The  simulation  is  implemented  using  Simulation  Language 
for  Alternative  Modeling  (SLAM  II).  The  network  orientation 
of  SLAM  II  is  used  to  represent  the  system  with  a  user 
written  FORTRAN  function  provided  to  determine  the  trans¬ 
mission  link  rates. 

A  valid  model  is  developed  from  a  widely  accepted 
analytical  analysis  of  a  star  network  similar  to  the 
proposed  system  at  Heidelberg.  The  final  validated  model  is 
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then  exercised  with  two  different  packet  switch  rates  and 
two  different  lirv^  speeds  of  the  telephone  swi tch-to-packet 
switch  interface.  ) 

The  simulation  results  show  that  with  the  originally 
proposed  configuration,  the  packet  switching  rate  was  not  a 
significant  factor  in  throughput  and  delay  measures.  The 
proposed  9600  bits/second  interface  between  the  packet 
switch  and  existing  telephone  switch  is  the  limiting  factor 
of  the  two  performance  measures. 

Among  the  recommendations  is  the  suggestion  that  an 
interface  with  a  higher  bit  rate  be  considered  since  this 
was  the  major  limitation  of  the  proposed  system. 


I 


I.  INTRODUCTION 


Overview 

As  computer  technology  advances,  more  information  is 
available  at  all  organizational  levels  in  business,  manufac¬ 
turing  and  the  military.  Low  cost  microcomputers  and  mini¬ 
computer  systems  have  paved  the  way  for  local  information 
processing  within  departments  or  communities  belonging  to 
larger  organizations.  Data  communications  networks  provide 
resource  sharing  capabilities  within  these  sub-organizations 
creating  "information  islands".  The  natural  progression  of 
communication  technology  is  to  integrate  these  islands  of 
information  into  one  organizational  information  system. 

This  provides  a  more  efficient  flow  of  information  between 
all  the  parts,  creating  a  more  cohesive  organization. 

Background 

A  requirement  exists  for  the  transmission  of  data  and 
voice  between  16  existing  approved  communications  networks 
(COMNETs)  at  various  levels  of  security  within  the 
Heidelberg  information  community  at  Heidelberg,  Germany. 
Tasking  for  this  requirement  was  assigned  to  the  Assistant 
Director  of  Information  Management,  1st  Information  Support 
Group,  by  letter  dated  23  July  1986,  from  HQ,  U.  S.  Army 
Europe  and  the  Seventh  Array.  The  U.  S  Army  Information 
Systems  Engineering  Command  -  Europe  is  managing  the  project 
and  is  sponsoring  this  thesis. 


The  goal  of  implementing  the  COMNET  interconnection 
backbone,  as  outlined  in  the  Capability  Requirements  (CAPR) 
Document  (9),  is  to  provide  a  complete  dev ice-to-dev ice  data 
processing  and  communications  network.  Dev ice-to-dev ice  is 
defined  as  personal  computer-to-per sonal  computer  (PC-to- 
PC),  PC-to-minicomputer ,  PC-to-mainframe,  rainicomputer-to- 
minicomputer ,  minicoroputer-to-mainframe  and  ma inf rame-to- 
mainf  rame . 

The  basic  user  requirements  outlined  in  the  CAPR  are: 

a)  To  provide  users  with  the  ability  to  connect  or 
disconnect  from  the  backbone  without  any  apparent 
interruption  to  the  user  of  any  other  device  operating  on 
the  system. 

b)  The  backbone  must  provide  users  with  the  ability  to 
interact  with  each  other  on  existing  COMNETs. 

c)  The  backbone  must  provide  for  expansion  as 
required . 

d)  The  backbone  must  provide  gateway  capabilities  to 
interface  with  other  Local  Area  Networks  (LANs)  as  required. 

The  sponsor  plans  to  implement  the  Integrated  Services 
Digital  Network  (ISDN)  as  the  baseline  architecture  for  the 
integration  of  data  and  voice  in  the  backbone  system.  This 
is  consistent  with  the  present  long-term  United  States  Army 
ISDN  policy  for  the  integration  of  data  and  voice  as  stated 
in : 
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1.  Department  of  the  Army  Policy  Letter,  9  November 
1984,  subject:  Policy  on  Army  Base  Communications. 

2.  HQ,  USAISC  Policy  Letter  85-1,  16  September  1985, 
subject:  Integrated  Services  Digital  Network  (ISDN)  Policy. 

3.  HQ,  USAISC  Letter,  27  February  1987,  subject:  USAISC 
Office  Automation  Policies. 

Based  on  the  ISDN  criteria,  the  goal  is  to  achieve  a 
data  rate  of  144Kbps  at  each  desk  terminal  and  move  toward 
fiber  optics  as  a  network  transmission  medium.  The  system 
must  support  about  2620  devices  of  approximately  eighteen 
different  vendors.  The  backbone  will  encompass  a  distance 
of  about  1.5Km  within  the  confines  of  the  Campbell  Barracks 
and  7.5Km  community  wide. 

Problem  Statement 

Headquarters,  U.  S.  Array  Information  Systems 
Engineering  Command  -  Europe  expressed  a  desire  for  a 
computer  simulation  model  to  be  constructed  and  exercised  to 
determine  the  feasibility,  throughput  and  delay  characteris¬ 
tics  of  the  proposed  COMNET  backbone. 

Purpose 

The  purpose  of  this  thesis  project  is  to  design  and 
analyze  by  simulation,  a  model  of  the  proposed  communications 
backbone  that  will  provide  interconnectivity  of  data  and 
voice  for  the  16  existing  independent  COMNETs  at  the 
Campbell  Barracks  in  Heidelberg,  Germany.  The  backbone  must 
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provide  gateways  to  connect  with  other  local  area  networks 
as  required.  The  Integrated  Services  Digital  Network  will 
be  used  as  a  basis  for  the  design.  The  sponsor's  proposed 
topology  is  a  fiber  optic  star  to  allow  integration  with  the 
existing  telephone  system,  that  provides  concentrators  and 
distributed  switches  for  future  growth. 


Summary  of  Current  Knowledge 

Integrated  Services  Digital  Network.  Conrad  described 
ISDN  as  a  modern  digital  system  aimed  directly  at  replacing 
the  present  analog  telephone  system  which  carries  virtually 
all  data  communication  traffic  (4:62).  ISDN  provides  its 
users  with  various  services  and  calling  features  across 
integrated  subscriber  loops  from  central  offices  by  way  of  a 
high  speed  digital  path  for  data,  facsimile,  videotext  and 
signaling  over  the  same  connection  as  voice.  These  services 
can  be  used  either  separately  or  simultaneously  by 
multiplexing  over  the  same  lines(3^2). 

From  a  users  perspective,  ISDN  offers  services,  proto¬ 
cols  and  performance.  From  a  control  perspective,  it  pro¬ 
vides  flexible  and  dynamic  connection  and  call  processing 
that  makes  the  many  integrated  services  available  to  the 
user.  Therefore,  a  model  of  ISDN  should  allow  the  represen¬ 
tation  of  the  various  services  seen  from  the  user's  perspec¬ 
tive  (11:  157). 


ft -.“.s' 
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In  developing  ISDN  protocol  and  architecture  models, 
Potter  stated  that  the  generic  pieces  to  any  model  of 
teletraffic  studies  should  include  the  following: 

a)  underlying  services  requested  by  users  which 
produce  the  input  traffic  demand  distribution, 

b)  the  signaling  control  provided  by  the  network  or 
user  for 

i)  connect i ons  -  needed  for  the  transport  of  the 
demand  traffic,  the  routing,  availability  of  resources 
as  well  as  guaranteeing  a  request  or  expected  grade  of 
service , 

ii)  calls  -  since  ISDN  provides  user  controlled 
functionality,  flexibility  of  possible  configurations 
and  versatility  of  access  to  the  network  or  remote  data 
bases  currently  being  designed  into  both  ISDN  access 
protocols  and  internetwork  protocols, 

c)  the  implicit  level  of  performance  of  the  signaling 
network,  protocols,  network  switches,  relay  points,  data 
bases,  internetworking  units  and  resource  availability, 

d)  the  cost  to  provide  a  particular  level  of  service. 

(  11:157) 

Potter  noted  that  before  an  appropriate  ISDN  model  can 
be  developed,  various  information  flows  (user  and  signaling 
information)  must  be  determined  (11:161).  In  ISDN  the 
information  flows  over  three  channel  types:  B,  D  and  H.  Over 
these  channels,  ISDN  provides  packet  and  circuit  switching 
capabilities  (15:  14^  —  151). 
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Conrad  (4:62)  examined  the  set  of  ISDN  interfaces  to 
provide  communication  between  local  as  well  as  non-local 
users  (see  Figure  1).  They  are  the  R,  S  and  T  interfaces. 
The  R  interface  provides  traditional  RS-232  or  equivalent 
non-ISDN  connections.  The  S  and  T  interfaces  are  ISDN 
digital  interfaces  with  multiple  B  and  D  channels.  He  noted 
that  European  carriers  provide  the  network  termination 
equipment  (NT1)  and  the  network  interface  equipment  (NT2). 

In  the  United  States,  the  users  are  free  to  acquire  their 
own  network  interface  equipment.  Therefore,  the  basic 
regulated  service  end  point  is  at  the  T  interface  rather 
than  the  S  interface  as  in  Europe. 

Conrad  also  noted  that  subscriber  terminal  equipment 
(ST1 )  is  fully  compatible  with  ISDN  requirements  and 
connects  directly  to  NT2  equipment.  ST 2  equipment  with 
interfaces  like  RS-232,  V.24/V.28,  X.21,  etc.  connect 
through  the  terminal  adapter  (TA)  which  provides  protocol 
conversion.  NT2  equipment  provides  protocol  handling, 
switching,  concentrating  and  multiplexing.  This  equipment 
typically  interfaces  with  other  networks  and  provides 
expansion  capabilities  for  the  system.  NT2  relates  to  the 
link  and  physical  layers  of  the  Open  Systems  Interconnect 
(OSI)  Model.  NT1  provides  the  electrical  termination  to 
the  customer.  It  is  basically  equivalent  to  the  physical 


In  summary,  ISDN  is  a  central  office  communication 
system  providing  end-to-end  digital  connectivity  with  user 
control  of  service  features.  Integration  of  voice  and  data 
is  provided  as  well  as  functional  integration  of  packet  and 
circuit  switching.  Connection  to  existing  analog  systems 
and  digital  communications  networks  is  provided  through 
common  physical  interfaces. 

Simulation.  A  simulation  is  the  imitation  of  the 
operation  of  a  real-world  process  or  system  over  time. 
Whether  done  by  hand  or  on  a  computer,  simulation  involves 
the  generation  of  an  artificial  history  of  a  system,  and  the 
observation  of  that  artificial  history,  to  draw  inferences 
concerning  the  operating  characteristics  of  the  real  system 
(2:2).  A  simulation  model  in  the  form  of  a  set  of  assump¬ 
tions  about  the  operation  of  a  system  is  necessary  to  under¬ 
stand  the  behavior  of  the  system  over  time.  A  model  is 
composed  of  a  collection  of  entities  with  associated  attri¬ 
butes.  Activities  represent  periods  of  time  in  a  system. 

The  state  of  a  system  is  a  collection  of  variables  at  any 
given  time.  Events  in  a  system  are  the  instantaneous 
changes  of  state  (8:127). 

Systems  can  be  categorized  as  discrete  or  continuous, 
but  few  systems  in  practice  are  wholly  discrete  or 
continuous.  However,  since  one  type  of  change  predominates 
for  most  systems,  it  will  usually  be  possible  to  classify  a 
system  as  being  discrete  or  continuous  (2:7).  Variables 
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change  at  discrete  points  of  time  in  a  discrete  system, 
where  in  a  continuous  system  the  variables  are  continually 
changing.  A  communications  system  is  characterized  as  a 
discrete  system  due  to  the  bursty,  non-continuous  nature  of 
its  traffic. 

Banks  and  Carson  pointed  out  that  the  simulation  model 
is  a  substitute  and  a  simplification  of  a  system  for 
purposes  of  study.  These  two  authors  noted  that  it  is  not 
necessary  to  consider  all  the  details  of  the  system; 
however,  it  must  be  sufficiently  detailed  to  permit  valid 
conclusions  to  be  made  about  the  real  system.  (2:9) 

Simulations  can  be  conducted  manually  or  with  the  aid 
of  a  computer.  Much  insight  can  be  gained  from  simulating 
small  systems  manually  but  real-world  systems  are  normally 
rather  large.  Since  the  amount  of  data  stored  and  manipu¬ 
lated  is  so  vast,  the  runs  are  normally  conducted  with  the 
aid  of  a  computer.  (2:11) 

Banks  and  Carson  also  noted  that  computer  simulation 
allows  the  state  of  a  system  to  be  changed  in  various  ways. 
Discrete  event  driven  simulations  are  based  on  a  simulation 
clock.  The  clock  advances  until  the  next  scheduled  event. 

The  user  is  free  to  vary  the  system  variables,  the  number  of 
entities,  the  relationship  between  entities,  and  the  values 
of  attributes  of  entities.  Statistics  collection  in  a  flexi¬ 
ble  simulation  program  gives  the  modeler  valuable  information 
to  iteratively  test  and  optimize  a  proposed  or  existing 
system.  (2:53) 


Schoeraaker  pointed  out  that  dangers  of  simulation  for 
the  modeler  include 

a)  wrong  designs  which  can  lead  to  an  unintentional 
wrong  projection  of  the  object  system  onto  the  target  system 
to  be  simulated. 

b)  wrong  coding  leading  to  incorrect  results. 

c)  wrong  tools.  A  general  purpose  programming  language 
can  mean  laborious  progress  while  a  special  purpose  language 
that  has  its  own  ’’view"  of  the  world  can  imply  intolerable 
constraints  on  the  model. 

d)  no  user/management  involvement  in  the  development 
and  implementation  process.  (14:80) 

That  danger  can  be  lessened  or  eliminated  with  the 
application  of  modern  software  engineering  principles. 
Verification  and  validation  principles  must  be  included  in 
the  evaluation  of  the  performance  of  the  simulation  model. 
Verification  determines  if  the  model  is  executing  as  was 
intended;  in  other  words,  is  the  modeler  building  the  system 
right? 

Validation  determines  if  the  model  is  a  proper  repre¬ 
sentation  of  the  system;  in  other  words,  is  the  modeler 
building  the  right  model?  Pritsker  states  that  validation 
of  simulation  models  may  be  difficult,  but  not  unreasonable 
because  of  the  correspondence  between  model  elements  and 
system  elements  (12:12). 
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Security  issues  are  not  addressed  in  this  thesis.  The 
system  is  treated  as  unclassified  in  all  modeling  and 
simulation . 

The  simulation  model  represents  the  backbone  that 
interconnects  approximately  2620  devices  distributed  among 
the  16  COMNETs  in  the  various  buildings  on  location. 
Throughput  and  delay  characteristics  are  determined  from 
the  simulation  runs. 

Approach 

A  simulation  model,  rather  than  analytical,  was 
requested  by  the  sponsor  to  provide  a  base  model  for  the 
network  as  it  grows  and  changes  over  time.  It  will  also 
provide  a  convenient  means  to  experiment  with  configuration 
changes  as  the  network  evolves  in  complexity.  This  thesis 
develops  a  valid  simulation  model  of  the  backbone  network 
that  represents  the  actual  system  that  is  proposed  at  the 
Campbell  Barracks.  A  computer  simulation  of  the  system  is 
exercised  to  determine  the  throughput  and  delay 
characteristics.  The  computer  simulation  allows  topology 
modifications  of  transmission  links  and  packet  switching 
rates  to  determine  the  optimal  configuration. 

The  steps  to  accomplish  these  goals  were: 

1)  Visit  the  Campbell  Barracks  to  conduct  a  thorough 


requirements  analysis  based  on  accepted  software  engineer¬ 
ing  principles  with  the  users  of  the  proposed  system. 


2)  Study  network  modeling  and  simulation  techniques  in 


general . 


3)  Design  the  network  system  model  for  the  proposed 
network . 

4)  Conduct  simulation  experiments. 

Simulation  Techniques  Study.  A  study  of  simulation  was 
conducted  to  obtain  a  working  knowledge  of  general  system 
simulation.  The  study  concentrated  on  discrete  event  simu¬ 
lation  because  of  the  non-continuous  nature  of  computer 
network  traffic.  Additionally,  a  computer  simulation  lan¬ 
guage  was  selected.  Features  considered  in  the  selection 
was  ease  of  use,  ability  to  accommodate  user  written  mod¬ 
ules,  ability  to  model  protocols,  clarity  of  the  generated 
statistics,  and  understandabi 1 ity  of  the  simulated  model 
when  reading  the  code. 

Network  Model ing  Study.  A  study  of  analytical  and 
computer  modeling  was  conducted  to  develop  techniques  that 
were  used  in  the  design  a  valid  model  of  the  actual  backbone 
network.  Proven  analytical  methods  that  apply  to  the 
topology  of  the  actual  network  were  researched.  This 
research  also  included  study  of  similar  models  that  have 
already  been  validated,  with  the  idea  of  modifying  them  to 
fit  the  constraints  of  this  thesis. 

Design  of  the  Network.  A  valid  detailed  design  of  a 
computer  network  model  was  developed.  This  was  done  by 
first  designing  a  model  of  a  subset  of  the  actual  network. 


Then  performance  characteristics,  message  delay  and 
throughput  for  example,  were  manually  calculated  for  the 
subnetwork  with  the  analytical  methods  developed  from  the 


network  modeling  study.  A  subset  was  used  because  of  the 
intractable  task  of  manually  analyzing  a  network  of  2620 
devices.  By  working  with  a  small  tractable  problem,  a 
computer  simulation  model  could  then  be  designed  and  its 
performance  results  compared  with  results  of  generally 
accepted  mathematical  methods.  By  designing  the  computer 
model  to  replicate  the  results  of  the  analytical  model,  a 
high  degree  of  confidence  is  achieved  that  the  computer 
model  is  accurate.  The  simulation  method  used  to  develop 
the  small  subnetwork  model  was  applied  to  the  complete 
network  problem  to  develop  an  overall  valid  solution. 

Simulation  Experiments.  The  experiments  were  conducted 
to  determine  throughput  and  delay  characteristics  of  the 
complete  network  under  various  topology  modifications  and 
load  variations.  They  were  designed  to  exercise  the  network 
under  controlled  conditions  according  to  requirements  that 
the  sponsor  provided.  One  of  the  experiments  was  to  study 
the  effects  on  throughput  of  varying  the  packet  switch  speed 
with  all  other  parameters  held  constant.  Another  was  to 
study  the  effects  of  various  link  speeds  in  the  network  on 
system  delay. 


Chapter  II  presents  the  development  of  the  model  and 


the  simulation  methods  that  were  actually  used.  A 
simulation  language  is  determined  based  on  its  ability  to 
provide  a  flexible  and  accurate  representation  of  the 
system.  In  order  to  establish  a  high  degree  of  confidence 
in  the  simulation  model,  analytical  studies  are  conducted  to 
determine  its  validity.  Coding  methodologies  are  presented 
for  the  program  modules  of  the  simulated  system. 

Chapter  III  presents  the  Heidelberg  model  and  the 
detailed  description  of  the  code  used  to  represent  that 
model.  Documentation  of  the  code  is  also  presented  in  the 
form  of  SLAM  II  network  diagrams. 

Chapter  IV  presents  the  experiments  that  were  conducted 
to  derive  the  characteristic  delay  curves  for  the  backbone 
system . 

Chapter  V  includes  the  thesis  summary  with  conclusions 
and  recommendations. 


II.  MODEL  DEVELOPMENT 

Introduction 

The  objective  of  this  chapter  is  to  develop  the 
simulation  model  of  the  proposed  Heidelberg  system.  The 
final  simulation  model  is  developed  by  first  establishing  a 
baseline  model  validated  against  known  analytical  results  of 
a  system  similar  to  the  one  at  Campbell  Barracks.  Then  the 
validated  baseline  model  is  expanded  to  represent  the  actual 
proposed  network. 

The  Heidelberg  System 

In  order  to  validate  the  software  model,  it  must  be 
shown  that  the  model  accurately  represents  the  actual  system 
being  modeled.  The  actual  system  at  Heidelberg  will  be 
built  around  an  ISDN  oriented  switch  in  a  star  configura¬ 
tion.  Data  traffic  from  terminals,  hosts  and  other  data 
devices  will  be  transmitted  to  and  be  routed  by  the  switch. 
Information  collected  during  the  requirements  analysis  site 
survey  indicates  that  a  phased  approach  will  be  used  in 
building  the  final  system. 

In  the  first  phase,  a  stand-alone  packet  switch  will  be 
installed  near  the  existing  European  Telephone  System  (ETS) 
telephone  switch  gear.  Only  hosts  in  the  Heidelberg  infor¬ 
mation  community  will  be  connected  in  this  packet  switched 
network.  This  basically  includes  minicomputers  (e.g  VAX 
11/XXX  series  or  a  machine  of  equivalent  performance)  and 


mainframes.  Some  of  those  hosts  have  back  end  Local  Area 
Networks  (LANs)  connected.  Existing  spare  twisted  pair  will 
be  used  to  interconnect  approximately  20  hosts. 

Phase  2  is  planned  to  integrate  the  existing  non-host 
oriented  LANs  into  an  ISDN  oriented  system.  This  will 
consist  of  an  upgrade  of  the  ETS  by  changing  the  analog 
subscriber  loops  to  digital  subscriber  loops.  The  existing 
telephone  "Key  Systems"  will  be  abandoned  in  favor  of  a 
single  line  concept  for  each  digital  telephone  and  data 
device.  In  a  pure  ISDN  system  the  telephone  and  data  termi¬ 
nal  can  be  an  integrated  ISDN  device.  Otherwise,  a  non-ISDN 
data  device  or  LAN  gateway  is  interfaced  with  a  terminal 
adapter  (TA)  and  multiplexed  to  the  ISDN  switch  via  an  NT2 
device  (also  generically  referred  to  as  a  gateway).  This 
will  require  multiplexing  over  fiber  optic  links  since  the 
number  of  existing  twisted  pair  is  not  adequate  for  a  single 
line  concept.  Fiber  optics  will  be  used  to  be  consistent 
with  the  U.S.  Army  policies  stated  in  Chapter  1. 

The  packet  switch  will  be  interfaced  with  the  ETS 
through  a  data  link  level  connection.  This  interface  will 
run  the  LAP-D  link  access  protocol  (1:1-12).  This  will  allow 
access  to  the  20  hosts  of  the  Phase  I  network  from  terminals 
in  existing  non-host  LANs  or  ISDN  data  devices  connected  to 
the  ETS.  Only  data  channels,  no  voice,  will  be  modeled  in 


this  thesis. 


The  Model 

In  addition  to  the  20  hosts  that  will  be  connected  in 
Phase  I,  approximately  16  existing  LANs  of  major  organiza¬ 
tions  located  at  Campbell  Barracks  will  be  interconnected  to 
the  packet  switched  network  via  the  ETS  through  gateways  in 
Phase  II.  Therefore,  a  model  of  the  data  portion  of  a 
future  ISDN  oriented  network  will  consist  of  20  hosts  con¬ 
nected  directly  to  the  packet  switch  and  16  gateway  inputs 
from  existing  LANs  (see  Figure  2).  As  the  network  grows, 
the  sponsor  will  be  able  to  modify  the  model  to  reflect 
expected  growth;  for  example,  impacts  of  future  ISDN  data 
devices  connected  to  the  ETS  when  the  number  of  these 
devices  is  known. 


Figure  2.  Phase  II  Network  Configuration 


Simulation  Language 

The  computer  simulation  language  chosen  for  for  the 
model  is  SLAM  II  -  Simulation  Language  for  Alternative 
Modeling.  SLAM  II  is  a  FORTRAN  based  language  developed  by 
Pritsker  and  Associates  (12).  It  supports  three  views  of 
model ing : 

a)  discrete  event 

b)  continuous 

c)  network 

The  network  view  is  used  in  this  thesis.  This  view  uses 
network  symbols  for  building  graphical  models  that  are 
easily  translated  to  code  input  statements  for  direct 
computer  processing. 

SLAM  II  was  chosen  because  the  graphical  network 
symbols  provide  easy  to  understand  documentation  of  program 
flow  and  simple  translation  to  code.  Also,  future  modifica¬ 
tion  or  expansion  of  the  model  will  be  simple  due  to  the 
clarity  of  the  logical  network  symbols  as  well  as  the 
ability  of  SLAM  II  to  integrate  user  written  FORTRAN  event 
modules  and  user  functions.  This  allows  flexibility  to  meet 
future  simulation  needs  of  the  sponsor  or  configuration 
changes  to  the  network. 

Classical  Analytical  Model 

Much  widely  accepted  analytical  work  in  queueing  theory 
and  network  analysis  has  been  done  by  Kleinrock  (10).  He 
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represents  a  computer  network  as  an  unsteady  flow  of 
messages  through  a  network  of  channels  between  nodes.  This 
unsteady,  or  stochastic,  flow  means  that  the  time  between 
arrivals  to  the  system  and  the  demand  placed  on  the  channels 
by  these  arrivals  are  random  quantities.  Unlike  steady 
flow,  a  queue  may  form  during  stochastic  flow  even  if  the 
average  flow  rate  does  not  exceed  the  channel  capacity. 
However,  the  queue  length  remains  finite  (10:5). 

One  of  Kleinrock’s  investigations  centered  around  the 
stochastic  flow  of  messages  through  a  network  of  communica¬ 
tions  centers.  He  noted  that  queues  of  messages  form  at  the 
network  nodes  due  to  the  sporadic  message  flow,  thus  requir¬ 
ing  some  form  of  storage  at  each  node.  His  single  most 
significant  measure  of  performance  is  average  message  delay. 
This  is  the  time  for  a  message  to  travel  from  origin  to 
destination.  A  traffic  matrix  whose  entries,  are  use^ 

to  describe  the  average  number  of  messages  generated  per 
second,  having  an  origin  of  i  and  a  destination  of  j.  The 
external  traffic  entering  the  network  is  given  as  Y  = £  Y ^ ^ 

i  j 

(see  Figure  3). 

The  analytical  model  that  he  developed  is  based  on 
several  assumptions  to  provide  mathematical  ease  and  tracta- 
bility.  It  is  assumed  that  all  node-to-node  channels  are 
noiseless  and  intranode  delays  are  negligible.  Traffic  is 
considered  to  be  data  only  with  no  telephone  or  direct  wire 
traffic.  Each  message  has  a  single  destination  and  must 
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reach  its  destination  before  leaving  the  network.  Each  node 
is  assumed  to  have  unlimited  storage  capacity.  Origin  times 
and  lengths  of  messages  are  random  variables.  Interarrival 
times  between  messages  are  exponentially  distributed  (i.e. 
Poisson  process).  Message  lengths  are  also  exponentially 
distributed. 
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Each  node  in  the  network  is  represented  as  a  single 
server  queue  (see  Figure  M). 


Figure  4.  Single  Server  Queue 


The  Poisson  interarrival  rate  at  the  ith  node  is  Xj  messages 
per  second.  The  average  delay  for  the  ith  channel  is 


^Ci-  Xj 


The  arrival  rate  of  messages  to  all  channels  in  the  system 

is  X  =  JCXi*  The  total  averaged  delay  in  the  network  is 
i 

given  by 


T  =  Z 


Kleinrock  analyzed  a  five  node  network  in  a  star  top¬ 
ology  having  the  channel  capacities  (bits/second)  as  shown 
in  Figure  5  (10:19-33). 


Figure  5.  Kleinrock's  Star  Model 


Table  1  shows  the  traffic  matrix  he  used.  This  matrix 
represents  a  load  of  P  =  0.1,  1  / fJ.  =  0.1,  C  =  38.33  and 
y  -  38.33.  If  P  is  allowed  to  vary,  a  delay  curve  is  found 
using  equations  (2)  and  (3)  (see  Figure  6). 

Table  1. 

Kleinrock's  Input  Traffic  Matrix 


Baseline  Model 


A  baseline  SLAM  II  model  was  developed  by  Garcia  (7)  to 
simulate  Kleinrock's  five  node  analytical  model.  This  model 
validates  the  programming  technique  and  provides  a  basis  to 
expand  to  the  full  simulation  model  with  a  high  degree  of 
confidence  that  it  accurately  represents  the  actual  system. 

The  baseline  model  consists  of  four  modules: 

1.  Message  Generation 

2.  Node  Processing 

3.  Node-To-Node  Transmission 

4.  Statistics  Collection 

Figure  7  shows  the  SLAM  II  network  diagram  for  the  baseline 
model . 

The  message  generation  module  uses  the  traffic  matrix 
of  Table  1  as  input  to  the  network.  A  create  node  is 
implemented  for  each  entry  in  the  table.  The  time 

between  creations  is  exponentially  distributed  with  a  mean 
of  seconds.  The  assign  node  places  the  destination 

corresponding  to  y^j  into  attribute  2.  An  input  queue 
represents  each  node  inputting  traffic  to  the  system  over 
one  of  four  input  channels  to  the  central  node. 

The  node  processing  module  represents  the  central 
switching  node  only.  Messages  are  routed  to  the  proper  node 
based  on  attribute  2.  Messages  destined  for  the  central 
node  are  sent  directly  to  the  statistics  module  and 


terminated . 
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The  node-to-node  transmission  module  consists  of 
service  activities  of  a  duration  of  (1//0/Cj  seconds.  Each 
queue/service  activity  represents  one  of  the  four  output 
channels  from  the  central  node. 

The  mean  message  delay  is  collected  by  the  collect  node 
TOT.  Each  entity's  time  in  the  system  is  recorded  and  the 
final  total  network  mean  delay  is  reported  in  the  SLAM  II 
summary  report. 

Figure  8  shows  the  system  delay  results  of  the  SLAM  II 
baseline  model  compared  with  those  of  Kleinrock's  analytical 
model.  Based  on  this  comparison,  it  is  shown  that  the 
baseline  model  is  a  valid  basic  design  upon  which  to  con¬ 
struct  the  full  model. 


Model  I 

Model  I  was  developed  from  the  baseline  model  to  expand 
the  channel  links  to  include  link  transmission  errors  and  a 
link  level  ACK/NAK  protocol  along  the  lines  of  the  work  done 
by  Garcia.  SLAM  II  queues  were  changed  to  await  nodes  and 
the  channels  represented  as  resources.  This  allows  the 
ACK/NAK  and  error  functions  to  complete  while  the  next 
message  in  the  queue  waits  for  the  channel  resource  to 
become  available.  A  working  five  node  Model  I  was  completed 
that  gave  consistent  results  with  the  baseline  model.  The 
next  step  was  to  expand  the  model  to  the  size  and 
configuration  of  the  proposed  Heidelberg  network. 


Time  (seconds) 


Analytical  x 
Baseline  . 


Figure  8.  Baseline  vs  Analytical  Delay  Curves 
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The  only  basic  difference  between  the  Heidelberg  system 
and  Kleinrock's  model  is  that  the  ISDN  switching  node 
contributes  no  original  traffic  and  has  intranode  delay. 
Using  Garcia's  technique,  one  input  queue  is  required  for 
each  node.  Therefore,  n  nodes  require  n  queues  with  n-1 
create  nodes  per  input  queue  (see  Figure  7).  The  Heidelberg 
model  has  36  input  nodes.  That  would  require  36  input 
queues  with  35  create  nodes  per  queue.  That  means  1260 
create  nodes  must  be  coded  to  represent  each  non-diagonal 
entry  of  the  input  traffic  matrix,  minus  those  for  the 
central  node  representing  the  ISDN  switch  since  they 
contribute  no  external  traffic. 

Traffic  Input.  The  expected  traffic  input  to  the 
Heidelberg  network  is  unknown.  Therefore,  it  was  decided  to 
assign  equal  input  traffic  rates,  y  ^  j ,  for  each  traffic 
matrix  entry  for  an  overall  network  traffic  input  of  y  cal¬ 
culated  at  a  given  utilization  rate  of  P.  Each  p  corre¬ 
sponds  to  a  value  of  packets/second  input  to  the  network. 
This  will  give  a  delay  character istic  of  the  network  at 
various  loads.  According  to  Kleinrock,  a  highly  non-uniform 
traffic  pattern  will  yield  a  minimum  message  delay  (10:122). 
Since  the  expected  traffic  is  unknown,  a  uniform  traffic 
pattern  should  give  worst  case  delay  for  the  system  under 
study,  which  is  a  desirable  measure  of  performance.  In 
light  of  this,  each  create  node  will  have  the  same  mean 
interarrival  rate  for  its  exponential  distribution.  Since 


Poisson  processes  are  additive,  it  was  recognized  that  the 
message  creation  module  could  be  redesigned  with  one  create 
node  representing  the  overall  network  traffic  input.  The 
mean  packet  inter-arrival  rate  is  then  1/y.  The 
source/destination  pairs  are  now  determined  for  each  message 
from  uniform  distributions  between  1  and  36. 

Model  n 

The  final  working  model,  Model  II,  was  designed  from 
lessons  learned  in  the  development  of  Model  I.  The  first 
version  of  Model  II  was  built  to  verify  the  idea  that  one 
create  node  with  a  mean  interarrival  time  of  1/y  is  equiva¬ 
lent  to  n  -  1  create  nodes  inputting  n  queues. 

Again,  the  data  of  Table  1  was  used  to  verify  that 
Model  II  was  equivalent  to  the  baseline  model.  The  redis¬ 
tribution  of  the  data  to  make  each  yi  j  of  equal  value  was 
obtained  by  dividing  y  (the  overall  external  input  to  the 
network)  by  the  number  of  j  entries;  i.e.  38.  33/20  =  1.91  6 

messages/second  at  p  -  0.1.  The  baseline  model  was  used  to 
develop  a  delay  curve  as  P  was  varied. 

Model  II  was  set  up  with  one  create  module  representing 
inputs  from  all  nodes  except  the  central  node.  This  repre¬ 
sents  16/20  of  the  total  network  traffic  input.  Another 
create  module  representing  input  traffic  from  the  central 
node  contributes  4/20  of  the  total.  Two  modules  were 
actually  used  since  external  traffic  generated  at  the 


32 


central  node  is  input  to  the  network  output  queues  while  the 
other  nodes  input  to  the  network  input  queues.  The  central 
node  is  again  represented  as  an  activity  with  no  delay  (see 
N 1  in  Figure  9)  ■ 

Slam  II  allows  multiple  queues  to  be  represented  with  a 
single  await  node.  Each  queue  is  associated  with  a  link. 

The  effect  is  equivalent  to  the  discrete  queues  and 
activities  of  Figure  7.  When  the  link  is  free,  the  proper 
path  is  selected  by  either  source  or  destination.  Figure 
9  is  logically  equivalent  to  Figure  7* 

The  mean  interarrival  rate  for  input  nodes  is  then 
(20/16)  x  (  1  /y) ,  and  for  the  central  node,  (20/4)  x  (1/y). 
The  source  values  were  determined  from  the  uniform 
distribution  of  2  to  5  for  the  input  nodes.  The  source  is 
always  1  for  the  central  node.  All  destinations  were 
determined  from  the  uniform  distribution  of  1  to  5.  Again  p 
was  varied  and  Model  II  was  used  to  develop  a  new  delay 
curve.  Figure  10  shows  that  the  two  curves  are  nearly 
identical.  Therefore,  it  is  shown  that  Model  II  is  accurate 
and  that  the  method  of  using  interarrival  rates  based  on  y, 
or  a  proportion  of  y  if  more  than  one  module  is  used,  is 
equivalent  to  one  create  node  for  each  entry  of  the  input 
traffic  matrix.  This  will  drastically  reduce  the  amount  of 
source  code  and  keep  the  model  compact.  It  still  provides 
flexibility  because  if  some  individual  channels  must  be 
modeled  separately,  they  can  be  represented  with  separate 
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create  modules  with  the  interarrival  rates  adjusted  propor¬ 
tionately  across  all  inputs. 

Summary 

This  chapter  explained  the  process  that  was  used  to 
develop  a  simulation  model  that  was  based  on  widely  accepted 
analytical  work  done  on  a  network  similar  to  the  proposed 
communications  backbone  at  Campbell  Barracks  in  Heidelberg. 

A  programming  technique  for  a  simulation  model  was  found 
that  accurately  simulated  the  analytical  model  thus 
providing  a  basis  for  validating  the  model.  That  simulation 
model  was  modified  to  minimize  the  amount  of  source  code  and 
to  more  efficiently  represent  the  type  of  data  to  be  run  in 
the  simulation.  This  keeps  the  program  manageable  and 
simple  while  maintaining  a  high  degree  of  confidence  that  it 
accurately  represents  the  actual  system.  The  results  of  the 
modification  were  verified  against  the  baseline  model  for 
accuracy.  The  final  product  is  Model  II  which  was  validated 
and  verified  against  accepted  analytical  results. 


III.  THE  HEIDELBERG  MODEL 


Introduction 

Using  the  concepts  developed  in  Chapter  2,  Model  II  is 
expanded  to  represent  the  COMNET  backbone  at  Heidelberg. 

This  chapter  describes  variables  and  attributes  used  in  the 
code,  the  data  flow  diagram  that  represents  the  model  and  a 
description  of  the  SLAM  II  code  that  is  derived  from  the 
network  diagrams.  The  SLAM  II  network  diagrams  are 
contained  in  Appendix  2. 

Variables  and  Attributes 

Table  2  lists  the  SLAM  II  variables  and  with  functions. 


Table  2 

SLAM  II  Variables 


Variable 

Function 

XX  ( 1 ) 

gateway  interarrival 

time 

( seconds ) 

XX(2) 

host  interarrival  time 

(seconds) 

XX  (  3 ) 

mean  packet  size 

( bits ) 

XX(4) 

minimum  packet  size 

(bits ) 

XX  ( 5 ) 

maximum  packet  size 

(bits) 

XX  ( 6 ) 

ETS-PS  1  ink  rate 

(bits/sec ) 

XX  ( 7 ) 

ACK/NAK  packet  size 

(bits) 

XX  ( 8 ) 

error  rate 

XX  ( 9 ) 

number  of  hosts 

XX ( 10) 

packet  switch  rate 

(bits/sec ) 

XX  (  1  1  ) 

number  of  channels  + 

2 

XX  (  1 2  ) 

ETS  overhead 

( seconds ) 

A  detailed  description  of  each  variable  is  contained  in 
Appendix  1 . 
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Table  3  lists  the  attribute  values  for  each  entity  that 
traverses  the  network. 


Table  3 


Attributes 


Attribute 


Function 

creation  time 

destination 

source 

channel  number 
queue 

packet  length 
transmission  rate 


A  detailed  description  of  each  attribute  is  contained 


in  Appendix  1 


Code  Description 


The  data  flow  diagrams  of  the  Heidelberg  model  are 
shown  in  Figure  11.  They  illustrate  the  packet  flow  in  the 
four  modules  in  which  the  actual  SLAM  II  code  is  organized. 
The  modules  are: 

a)  Input  Module 

b)  Transmission  Module 

c)  Switch  Processing  Module 

d)  Output  Module 

The  actual  SLAM  II  network  diagrams  of  the  modules  from 
which  the  SLAM  II  code  is  derived  are  illustrated  in 
Appendix  2. 
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Input  Modu 1 e.  The  input  module  begins  with  a  create 
node  inputting  entities  with  exponentially  distributed 
interarrival  times.  Gateway  input  to  the  ETS  is  represented 
with  one  input  module.  Host  input  to  the  packet  switch  is 
represented  with  another.  This  was  done  for  ease  of 
representing  different  channel  transmission  rates  for  hosts 
and  gateways.  A  source/destination  pair  is  then  determined 
with  two  uniform  distributions  with  different  seed  streams. 
Based  on  these  source/destination  values,  an  input  queue, 
represented  by  an  await  node,  and  a  channel,  represented  by 
a  resource,  are  selected.  The  packet  length  is  determined 
from  an  exponential  distribution  with  XX(3)  being  the  mean 
value.  A  range  of  packet  sizes  can  be  enforced  by  using 
XX(4),  the  minimum  value,  and  XX(5),  the  maximum  value.  The 
packet  is  then  assigned  a  transmission  rate  by  USERF(I)  and 
stored  in  RATE.  It  then  awaits  in  its  appropriate  queue  for 
transmission  over  a  free  channel. 

Transmission  Modu 1 e.  The  transmission  link  from  a 
gateway  to  the  central  node  is  represented  as  shown  in 
Figure  11.  When  the  transmission  link  is  free  the  errorless 
link  sends  an  entity  directly  to  the  FREE  node  at  the 
transmission  speed  of  LENGTH/RATE.  However,  when 
transmission  errors  are  modeled,  the  error  branch  is  taken  a 
percentage  of  the  time  corresponding  to  the  transmission 
error  rate.  The  NAK  is  sent  and  another  probability  branch 
is  taken.  When  a  good  packet  is  eventually  sent,  the  branch 


Processing  Module 


is  to  complete  the  transmission  at  the  transmission  speed  of 
LENGTH/RATE.  The  link  is  then  freed  to  allow  the  next 
packet  transmission.  The  ACK/NAK  packet  size  is  held  in 
XX(8).  The  transmission  error  probability  branch  decision 
is  based  on  the  contents  of  XX(9).  The  transmission  rate  is 
determined  in  USERF(I)  and  stored  in  RATE.  This  rate 
depends  on  whether  a  packet  is  transmitted  from  a  gateway  or 
a  host.  When  the  transmission  is  complete,  the  link  is 
freed  for  transmission  of  the  next  packet  in  the  queue. 

Switch  Processing  Modu 1 e.  The  switch  processing  module 
of  Figure  11  represents  the  ETS,  the  link  between  the  ETS 
and  packet  switch  (ETS-PS  link),  and  the  packet  switch 
overhead.  The  ETS  processing  overhead  is  assumed  to  be 
negligible  compared  to  the  combined  processing  overhead  of 
the  ETS-PS  link  and  the  packet  switch.  When  the  entity 
representing  a  packet  enters  the  switch  processing  module  at 
node  N1  from  a  transmission  module,  a  decision  is  made, 
based  on  the  source,  to  determine  if  it  is  assigned  to  the 
packet  switch  queue  directly  or  if  it  must  traverse  the  ETS- 
PS  link  first.  The  ETS-PS  link  operates  the  same  as  the 
transmission  link.  After  the  packet  switch  processing,  the 
destination  attribute  DEST  determines  if  the  ETS-PS  link 
must  be  traversed  in  the  case  of  the  destination  being  a 
gateway.  Otherwise,  the  entity  is  routed  directly  to  the 
output  module  via  N2  in  the  case  of  a  host  destination. 


The  ETS-PS  link  is  interfaced  to  the  two  switches  by 
the  LAP-D  protocol  which  is  a  version  of  the  High  Level  Data 
Link  Control  (HDLC).  This  protocol  allows  many  bidirec¬ 
tional  logical  links  across  one  interface.  It  assigns  each 
logical  link  an  identity  and  provides  each  with  transmission 
error  recovery  and  flow  control  (1:1-12).  This  link  was 
therefore  represented  as  other  channel  links  providing  the 
low  level  error  recovery. 

Output  Modu 1 e.  The  source  designation  from  the  switch 
is  always  a  1  and  is  assigned  to  SRC.  The  destination  queue 
and  channel  are  derived  from  DEST.  The  channel  transmission 
rate  is  determined  from  USERF(I)  based  on  DEST.  The  entity 
representing  a  packet  waits  in  the  assigned  output  queue 
until  the  appropriate  channel  is  free.  Again,  the  trans¬ 
mission  error  probability  branch  decision  is  determined  by 
XX(9)  as  in  the  transmission  module. 

The  collect  node  STAT  calculates  the  mean  delay  for  the 
network  by  averaging  the  differences  of  an  entity's  creation 
time  in  attribute  1  and  the  current  time  when  any  entity 
arrives  at  the  collect  node.  The  entity  is  then  terminated 
after  the  delay  is  calculated. 

USERF ( 1 ).  This  FORTRAN  user  function  is  used  to  make 
logical  decisions  in  determining  the  particular  channel 
transmission  rates  based  on  the  source  or  destination.  This 
function  can  also  be  used  to  make  other  logical  decisions 
that  can't  be  done  efficiently  in  SLAM  II  code.  This  could 
be  of  importance  in  future  model  expansion. 


Entities.  It  was  experimentally  determined  with  a 
pilot  run,  that  at  least  100,000  entities  must  be  collected 
to  get  a  reliable  delay  curve.  The  horizontal  portion  of 
the  curve  can  be  consistently  reproduced  with  various  seed 
streams  for  the  input  distribution  with  less  than  10,000 
entities.  Howeve".  as  the  queue  lengths  become  longer  with 
higher  loads,  th-.-  variability  of  the  average  waiting  time  is 
greater  for  each  entity  and  so  it  necessary  to  collect  the 
larger  amount  in  order  to  reproduce  the  vertical  portion  of 
the  curve  that  is  consistent  between  runs.  A  collection  of 
150,000  entities  did  not  significantly  improve  the 
consistency,  so  100,000  was  chosen. 


IV.  EXPERIMENTS 

Introduction 

The  objective  of  this  chapter  is  to  explain  the 
experiments  that  were  run  to  exercise  the  model  and  to  show 
their  results.  The  results  will  characterize  the  network 
performance  as  a  consequence  of  varying  several  network 
parameters  that  define  the  network.  These  parameters 
include  channel  transmission  rate,  ETS-PS  link  transmission 
rate  and  packet  switch  processing  rate. 

It  was  decided,  in  agreement  with  the  sponsor,  to 
concentrate  this  effort  on  the  analysis  of  the  the 
characteristics  of  the  COMNET  backbone.  Other  aspects  of 
the  ISDN  system  can  be  studied  with  subsequent  efforts. 

This  chapter  explains  the  experimental  simulation  runs 
in  two  parts.  The  first  part  contains  results  of  two  runs 
conducted  on  the  Phase  I  model.  The  first  run  used  a  packet 
switch  rate  of  160  packets/second.  The  second  was  run  with 
a  packet  switch  rate  of  400  packets/second.  Ui  other 
parameters  were  held  constant. 

The  second  part  explains  the  three  series  of  simulation 
runs  that  were  conducted  on  the  Phase  II  full  model.  The 
first  series  was  modeled  with  the  ETS-PS  link  transmission 
rate  at  9.6K  bits/second.  Runs  were  then  conducted  with 
packet  switch  rates  of  160  packets/second  and  then  400 
packets/second.  The  second  series  was  conducted  in  the  same 


manner  as  the  first  with  the  only  difference  being  the  ETS- 
PS  link  rate  of  64k  bits/second.  A  third  series  of  runs  was 
conducted  to  show  the  effects  of  various  transmission  error 
rates  on  system  delay. 

General  Assumptions 

At  the  time  this  thesis  project  began  there  were 
several  unknowns  about  the  proposed  system.  Therefore, 
reasonable  assumptions  were  made  to  fill  the  gaps  and 
proceed  with  the  analysis  from  a  realistic  starting  point 
based  on  input  from  the  sponsor. 

The  packet  switch  computer  was  expected  to  be  in  the 
class  of  the  Bolt  Beranek  and  Newman  (BBN)  C/30.  Deter¬ 
mining  throughput  of  a  computer  can  be  a  vague  and  even 
controversial  matter.  Nevertheless,  for  purposes  of  this 
model  the  metric  for  throughput  is  packets/second.  The  C/30 
processes  approximately  160  packets/second  with  an  average 
packet  size  of  750  bits  in  the  ARPANET  applications  (6:38). 
This  throughput  value  was  used  in  the  model. 

The  packet  sizes  are  exponentially  distributed,  based 
on  Kleinrock's  assumptions,  with  a  mean  of  750  bits.  The 
maximum  and  minimum  limits  of  1  024  bits  and  256  bits 
respectively  are  used  as  the  packet  size  range  (13:83). 

In  order  to  model  the  effects  of  the  packet  switching 
rate  on  the  network,  a  BBN  C/300  was  also  used  in  the  model 
as  a  comparison  against  the  C/30.  The  C/300  switches  400 
packets/second  with  an  average  packet  size  of  750  bits. 


The  ETS-PS  link  transmission  rate  was  given  by  the 


sponsor  to  be  9600  bits/second.  At  first  glance,  it 
appeared  that  this  could  be  a  potential  bottleneck  in  the 
system.  Therefore,  the  sponsor  was  contacted  to  verify  this 
link  rate.  An  affirmative  reply  was  followed  up  with  a  copy 
of  Defense  Data  Network,  Installation,  Test,  and  Acceptance 
Guide  (5).  In  that  reference,  rates  of  several  interfaces 
for  the  C/30  were  researched.  It  was  found  that  five  basic 
inter-switch  trunk  rates  are  used  in  Defense  Data  Network 
applications  using  the  C/30.  They  are  9.6K,  19. 2K,  50K,  56K 
and  64K,  all  in  bits/second  (5:2-9).  In  light  of  this  added 
information,  it  was  decided  to  bracket  this  range  by 
modeling  the  9600,  being  the  slowest,  and  the  64K,  the 
fastest,  to  show  the  effects  of  the  ETS-PS  link  transmission 
rate  on  the  system. 

The  host  transmission  channel  speed  was  given  to  be  64K 
bits/second.  This  rate  was  used  in  all  experimental  runs. 
The  channel  transmission  rate  on  the  ETS  side  of  the  switch 
was  given  to  be  144K  bits/second  which  corresponds  to  a  2B+D 
ISDN  channel.  The  greatest  number  of  devices  in  the 
COMNETs  will  probably  be  terminals  typically  operating  at 
9600  bits/second.  A  D  channel  would  be  capable  of  carrying 
some  of  that  traffic  as  well.  Therefore,  experimental  runs 
were  included  to  show  the  network  characteristics  with  D 
channel  transmission  rates  at  the  same  capacity  as  the  2B+D 


channel . 


The  expected  network  input  traffic  load  was  an  unknown 
parameter.  Therefore,  the  traffic  input  from  each  source 
was  made  equal  within  its  own  class  of  traffic,  i.e.  host  or 
terminal.  The  total  network  capacity  is  the  sum  of  all 
individual  channel  capacities.  In  the  case  of  the  full 
system,  all  host  channels  were  assumed  to  be  input  with 
equal  traffic  intensity  and  all  gateway  channels  input  with 
equal  traffic  intensity.  These  two  classes  of  input  were 
proportioned  according  to  contribution  each  class  made  to 
the  total  network  traffic  input.  For  example,  if  host 
channel  capacity  is  80%  and  gateway  channel  capacity  is  20% 
of  the  total  network  capacity,  then  the  input  traffic 
intensity  is  proportioned  accordingly. 

Each  simulation  of  a  given  configuration  consists  of 
three  runs  with  different  seeds  for  the  input  distribution. 
Each  plotted  point  of  the  network  delay  graphs  is  the 
average  of  the  three  runs  for  a  given  point.  In  all  runs, 
the  difference  between  any  one  point  and  its  average  was 
found  to  be  less  than  1%  in  the  active  region  of  the  curve 
to  the  left  of  the  knee.  This  low  error  is  expected  in  this 
region  and  is  convincing  evidence  that  the  simulator  is 
consistent.  A  warmup  period  of  100  seconds  was  used,  after 
which  the  statistics  were  cleared. 

The  simulation  runs  on  a  VAX  11/785  for  about  55  CPU 
minutes  per  data  point  when  collecting  100,000  entities  (see 
Chapter  3  for  reason  of  this  number  of  entities). 


Host-to-Host  Network 

As  described  previously,  Phase  I  will  provide  packet 
switched  interconnectivity  between  hosts  in  the  Heidelberg 
information  community.  Figure  1  illustrated  that  these 
hosts  will  connect  directly  to  the  packet  switch.  The  first 
simulation  run  was  made  with  a  packet  switch  rate  of  160 
packets/second,  a  channel  transmission  rate  of  64K 
bits/second  and  a  mean  packet  length  of  750  bits.  Calcula¬ 
tions  for  the  packet  interarrival  rate  (1/y)  at  P  =  0.1  are: 

C  =  64000  x  40  =  2560000  bits/sec 

V  =  0.0013333  packets/bit 

y  =  2560000  X  0.0013333  x  0.1  =  341.33  packets/sec 
1/y  =  0.002929694824  seconds/packet 
where  C  is  the  sum  of  all  channel  capacities,  “\/n  is  the 
packet  length  and  P  is  calculated  from  Equation  (1)  in 
Chapter  3. 

The  simulation  results  in  Figure  12  show  that  the  knee 
occurs  near  p  =  0.05.  The  total  network  input  traffic  of 
341.33  packets/second  occurs  at  a  utilization  factor  of  0.1. 
Therefore,  a  utilization  factor  of  0.0468  represents  a 
traffic  load  of  160  packets/second.  Note  that  this  is  the 
packet  switching  rate  of  the  C/30*  The  average  delay  can  be 
expected  to  be  less  than  0.08  seconds  while  the  traffic 
intensity  remains  below  the  packet  switch  capacity. 

A  similar  experiment  was  run  with  a  C/300  as  the  packet 
switch.  The  results  are  consistent  with  those  run  with  the 
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C/30.  The  knee  occurs  near  a  utilization  factor  of  0.1. 

The  utilization  factor  of  0.117  represents  a  traffic  load  of 
400  packets/second. 

The  delay  curves  of  Figure  12  show  that  throughput  is 
increased,  but  the  delay  is  not  significantly  decreased  with 
a  faster  packet  switch.  In  both  cases  the  delay  will  be 
less  than  .08  seconds  and  is  not  significantly  different 
between  curves  in  the  active  ranges  below  the  knees. 

Full  System 

The  characteristics  of  the  full  configuration  are 
illustrated  in  Figures  12  and  1 3.  The  simulation  runs  were 
designed  to  show  the  effects  of  the  ETS-PS  link  transmission 
rates  at  the  two  packet  switching  rates. 

The  interarrival  rates  (1 /Y)  were  calculated  from  the 
following  values  at  p  -  0.1,  where  t  subscripts  indicates 
terminal  traffic  on  the  ETS  side  and  h  subscripts  indicate 
host  traffic  on  the  packet  switch  side: 

Ct  =  144000  x  32  =  4608000  bits/sec 

Cft  =  64000  x  40  =  2560000  bits/sec 

fi  -  0.001333  packet/bit 

y  -  955.73  packets/sec 

Yt  =  614.4  packets/sec 

7^  =  341.33  packets/sec 

1/y t  =  0.0016276041  seconds 


1/yh  =  0.0029297161  seconds 


The  terminal  capacity  is  64.29?  and  host  capacity  is 
35.71J  of  the  total  network  capacity.  Therefore  the  total 
arrival  rate,  y  is  proportioned  as  such  to  arrive  at  the 
given  values  of  terminal  and  host  interarrival  rates. 

Run  1 ,  Figure  13  shows  the  conf igurati on  with  a  9600 
bits/second  ETS-PS  link  and  terminal  channel  transmission 
rates  of  144k  bits/second.  This  link  is  obviously  the 
slowest  component  in  the  system.  The  knee  occurs  near  a 
utilization  factor  of  0.001.  The  corresponding  utilization 
factor  for  9600  bits/sec  is  0.00133  or  12.9  packets/second. 
Therefore  it  is  shown  that  throughput  is  limited  by  the 
slowest  component  in  the  system,  i.e.  the  ETS-PS  link.  As 
can  be  expected,  a  faster  switch  will  not  increase  the 
throughput  in  this  configuration  and  the  curves  verify  this. 
The  average  delay  can  be  expected  to  be  below  0.18  seconds 
while  operating  below  a  utilization  factor  corresponding  to 
the  ETS-PS  link  rate.  There  is  no  significant  delay 
improvement  by  implementing  the  C/300  switch. 

Run  2.  The  capacity  assignments,  channel  transmission 
rates  and  interarrival  rate  for  Run  2  are  identical  to  Run 
1.  The  only  difference  is  the  ETS-PS  transmission  rate  which 
is  modeled  at  64000  bits/second.  Figure  14  shows  the  delay 
curve  of  this  configuration.  Based  on  Run  1,  it  would  be 
expected  that  the  knee  of  the  delay  curve  would  occur  near  a 
utilization  factor  in  this  configuration  corresponding  to 
64000  bits/second,  which  is  0.0089  or  85.33  packets/sec. 


Time  (seconds) 


Figure  13*  Average  Delay  with  9600  b/s  ETS-P£>  Link 
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The  actual  knee  occurs  near  a  utilization  factor  of  0.009- 
The  average  delay  in  this  configuration  can  be  expected  to 
be  less  than  0.08  seconds. 


In  Run  1  and  Run  2  it  was  shown  that  the  throughput  is 
limited  to  a  degree  by  the  ETS-PS  link  transmission  rate. 
The  higher  the  percentage  of  the  terminal  traffic  that  must 
traverse  the  ETS-PS  link,  the  more  significant  that  link 
becomes.  It  was  also  shown  that  the  network  delay  is  not 
significantly  affected  by  the  speed  of  the  two  packet 
switches . 

Figure  14  also  shows  how  channel  transmission  rate 
effects  the  average  network  delay.  If  the  network  traffic 
input  is  maintained  at  the  intensity  for  144K  bits/second 
gateway  channels  but  transmitted  at  1 6K  bits/second,  the 
ISDN  D  channel  rate,  the  delay  curve  is  translated  upward. 
Throughput  is  not  effected  by  this  change. 

Errors.  It  would  be  expected  that  transmission  errors 
would  increase  the  average  network  delay.  Figure  15  shows 
the  effect  on  average  network  delay  due  to  transmission 
errors  on  all  links.  The  simulation  was  run  with  160 
packets/second  and  a  64K  bits/second  link.  As  the 
percentage  of  errors  increase,  the  average  network  delay 
clearly  increases.  It  can  also  be  seen  that  as  the  error 
rate  increases  to  and  above  10%,  that  the  retransmissions 
begin  to  saturate  the  network  sooner  then  at  the  lower 
rates.  A  10%  error  rate  increases  the  average  delay  by 


about  15%,  a  25%  error  rate  increases  the  delay  by  about 
75%,  and  a  50%  error  rate  increases  the  delay  by  about  200%. 
Note  that  the  average  network  delay  increase  is  greater  than 
the  percent  of  error  retransmissions.  This  is  due  to  the 
retransmission  packets  that  must  be  sent  after  each  NAK. 
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y_;_  CONCLUSIONS  AND  RECOMMENDATIONS 

Summary 

The  purpose  of  this  thesis  projest  was  to  develop  a 
simulation  model  to  represent  and  analyze  the  proposed  ISDN 
oriented  COM  NET  backbone  of  the  Heidelberg  information 
community.  SLAM  II  was  chosen  as  the  simulation  language 
because  of  its  flexibility  and  expandability.  A  SLAM  II 
model  was  validated  against,  widely  accepted  analytical 
metnods.  The  model  was  then  expanded  and  modified  to 
reflect  the  Heidelberg  configuration.  Several  assumptions 
were  made  about  unknown  parameters  and  were  based  on 
published  information  about  similar  systems.  Experiments 
were  developed  to  exercise  the  model  and  examine  the  effects 
of  changing  several  of  the  parameters  that  are  critical  to 
the  performance  of  the  network. 

Conclusions 

Phase  I_  Network.  The  Phase  I  network  consisted  of  the 
packet  switch  and  only  hosts  connected  with  64k  bits/second 
transmission  links.  The  resultant  delay  curves  for  the 
Phase  I  network  show  that  throughput  is  limited  by  the 
packet  switching  rate.  The  average  delay  can  be  expected  to 
be  below  0.08  seconds  while  operating  at  a  network  packet 
arrival  rate  below  the  packet  switching  rate.  The  knee  of 
the  delay  curve  occurs  at  a  utilization  factor  corresponding 
to  the  packet  switch  rate.  It  is  also  shown  that  even 


though  a  C/300  packet  switch  processes  40%  more  packets  per 
second  than  a  C/30,  the  average  network  delay  is  not 
significantly  effected. 

Phase  II  Network.  The  Phase  II  network  is  the 
expansion  of  the  Phase  I  network  to  the  full  system  with 
terminal  traffic  connected  to  the  packet  switch  through  the 
ETS  and  the  ETS-PS  link.  Consistent  with  the  Phase  I 
results,  it  was  shown  that  an  insignificant  delay 
improvement  was  achieved  when  a  C/300  packet  switch  was 
compared  to  a  C/30.  Equation  2  showed  that  delay  is  a 
function  of  channel  capacity,  packet  size  and  the  packet 
arrival  rates  in  the  ideal  model.  However,  in  the  non-ideal 
network  the  node  processing  also  contributes  significantly 
to  the  average  network  delay. 

The  ETS-PS  link  was  considered,  in  this  model,  to  be 
part  of  the  node  processing  overhead.  It  was  shown  that  a 
system  with  the  9.6K  bits/second  link  had  an  average  delay 
3.66  times  greater  than  one  with  the  64K  bits/second  link. 
The  transmission  rate  of  that  link  was  also  a  major  limiting 
factor  on  throughput.  The  delay  curves  clearly  showed  a 
queue  saturation  point  near  the  utilization  factor 
corresponding  to  the  bits/second  rate  of  the  ETP-PS  link. 
Also,  the  more  traffic  traversing  the  ETS-PS  link  versus 
that  remaining  in  the  host  side  of  the  switch,  the  closer  to 
the  link  rate  will  the  throughput  be  limited.  It  should  be 
pointed  out  that  if  the  link  transmission  rate  was  increased 
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above  that  of  the  packet  switch  rate,  then  the  packet  switch 
rate  becomes  the  limiting  factor. 

The  maximum  average  network  delay  for  the  9.6K 
bits/second  ETS-PS  link  configuration  not  operating  in 
saturation  is  0.18  seconds.  That  same  value  for  the  6MK 
bits/second  ETS-PS  link  configuration  is  0.08  seconds. 

The  effects  of  transmission  errors  was  also  included. 

It  was  shown  that  error  rates  below  10%  will  not 
significantly  degrade  performance.  However,  at  10%  and 
above,  the  number  of  retransmissions,  in  response  to  the 
NAKs,  fills  the  queues  faster  causing  network  saturation. 

At  a  50%  error  rate  the  increase  in  delay  is  200%  above  the 
0%  delay  curve. 

A  summary  of  the  conclusions  is: 

Phase  I  Network : 

a)  The  maximum  average  network  delay  can  be  expected 
to  be  0.08  seconds. 

b)  The  average  network  delay  curve  knee  occurs  at  the 
packet  switch  rave,  which  is  the  throughput  limiter. 

c)  A  packet  switch  with  higher  throughput  than  a  C/30 
will  not  significantly  decrease  average  network  delay  as 
long  as  the  ETS-PS  link  rate  is  less  than  the  C/30. 

Phase  I 1  Network : 

a)  The  maximum  average  network  delay  with  the  9*6K 
bit/second  ETS-PS  link  can  be  expected  to  be  0.18  seconds. 

b)  The  maximum  average  network  delay  with  the  bMK 
bit/^econd  ETS-PS  link  can  be  expected  to  be  0.08  seconds. 


c)  As  long  as  the  ETS-PS  link  bit  rate  is  less  than 
the  C/30  packet  switch  bit  rate,  a  faster  packet  switch  will 
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not  significantly  effect  network  delay  or  throughput. 

d)  The  ETS-PS  link  is  the  throughput  limiter  as  long 
as  it  is  slower  than  the  packet  switch. 

e)  The  greater  the  proportion  of  terminal  traffic  from 
the  ETS,  the  closer  to  the  ETS-PS  bit  rate  is  the  throughput 
1 imi ted . 

Transmission  Error  Rate: 


a)  Transmission  error  rates  below  10X  do  not 
significantly  effect  performance. 

b)  The  percentage  increase  of  network  delay  is  greater 
than  the  corresponding  percentage  increase  of  error  rate  due 
to  packet  retransmissions. 


Recommendations 


a)  Packet  Switch.  Based  on  the  results  of  the 


simulation  runs,  there  appears  to  be  consistent  evidence 
that  as  long  as  the  ETS-PS  link  transmission  rate  is  below 
that  of  the  C/30  packet  switch,  a  faster  switch  is  not 
justified.  Therefore  a  C/30  that  switches  750  bit  packets 
at  160  packets/second  will  have  sufficient  capacity. 

b)  ETS-PS  Link.  The  major  limiting  factor  in  the 
network  simulation  runs  was  the  ETS-PS  link.  It  is 
recommended  that  the  64K  bits/second  link  be  considered  in 
place  of  the  9.6K  bits/second  link  in  order  to  maximize  the 
throughput  and  keep  the  average  delay  to  a  minimum.  If  a 


62 


link  capable  of  greater  than  64K  bits/second  is  chosen,  then 
the  packet  switch  rate  may  become  the  limiting  factor  and 
the  switch  capabilities  should  be  reevaluated. 


Further  Research.  The  sponsor  should  use  the  model 
developed  in  this  thesis  as  a  basis  upon  which  to  expand 
toward  a  more  complete  ISDN  system  model.  The  following 
items  should  be  done  to  further  build  upon  the  results 
obtained  in  this  thesis  for  the  COMNET  backbone. 

a)  An  assumption  of  this  model  was  that  all  gateway 
traffic  was  equally  distributed  since  there  were  no  network 
input  traffic  figures  available.  As  stated  previously,  this 
assumption  should  theoretically  give  worst  case  results  for 
the  average  user.  But,  studies  of  the  individual  COMNETS 
should  be  done  to  determine  more  accurately  how  much  traffic 
can  be  expected  from  each  gateway  in  order  to  develop  a 
model  that  more  accurately  represents  the  functioning  real 
system . 

b)  After  the  traffic  distribution  is  more  accurately 
determined,  SLAM  II  models  of  each  COMNET  can  be  built  to 
verify  the  studies.  The  power  of  the  simulation  model  is 
really  needed  in  this  case  where  expansion  with  unequal 
inputs  may  need  to  be  modeled. 

c)  Separate  backbone  model  input  modules  can  then  be 
constructed  if  any  gateways  significantly  differ  in  the 
expected  traffic  input.  It  would  be  expected  that  most 
organizational  COMNETs'  input  will  be  typically  similar  and 
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could  be  modeled  closely  with  the  techniques  of  this  thesis. 
Possible  exceptions  could  be  expected  from  a  personnel 
organization  with  a  heavy  inquiry  rate. 

d)  If  the  ETS-PS  bottleneck  is  resolved  and  an 
accurate  traffic  input  is  determined,  then  a  particular 
channel  may  be  found  to  be  a  bottleneck.  Multiple  channels 
may  be  represented  since  the  simulation  model  represents 
channels  as  SLAM  II  resources.  The  number  of  channels  can 
be  specified  in  the  resource  statement  of  the  code.  As  it 
now  stands  with  a  9-6 K  bits/second  ETS-PS  link,  concerns 
about  a  transmission  link  overload,  for  example  the  one  to 
the  personnel  center  at  the  Kilbern  Barracks,  is  not  an 
issue  due  to  that  ETS-PS  bottleneck. 

e)  When  the  model  of  the  physical  network  is  matured 
and  considered  to  be  a  confident  representation  of  the  real 
system,  then  various  services  that  ISDN  offers  could  be 
included  in  the  model.  The  dynamic  channel  assignments  in  a 
simultaneous  data/voice  connection  is  one  example. 

These  recommendations  reflect  the  direction  and 
sequence  of  further  development  that  would  have  been  taken 
in  this  thesis  if  time  and  resources  would  have  allowed. 
Every  effort  has  been  made  to  make  the  model  clear  and 
expandable  so  that  the  sponsor  can  continue  the  effort 
through  other  theses  or  through  in-house  efforts. 
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Appendix  1:  Variable  and  Attribute  Descriptions 


Variables. 

XX( 1 )  and  XX(2).  The  interarrival  rates  are  determined 
from  1 / y  .  If  gateway  traffic  is  80%  of  total  network 
channel  capacity  and  host  traffic  is  20%,  then  XX(1)  and 
XX(2)  are  likewise  proportioned. 

XX(3),  XX(4)  and  XX(5).  XX(3)  contains  the  mean  value 

to  be  used  for  the  exponentially  distributed  packet  size.  I 
an  upper  and  lower  limit  to  that  packet  size  is  used,  then 
XX(4)  contains  the  minimum  and  XX(5)  contains  the  maximum. 

XX(6).  Holds  the  value  of  the  ETS  to  packet  switch 
(ETS-PS)  link  rate. 

XX(7).  The  ACK/NAK  packet  size  was  determined  from 
typical  packet  overhead  of  64  to  256  bits  (13:83).  A  value 
of  256  bits  was  considered  to  be  a  reasonable  ACK/NAK  packet 
size  based  on  this  source. 


XX(8).  The  transmission  error  rate  is  used  as  the 
probability  branch  value  in  the  channels  and  ETS-PS  links. 

XX(9)  and  XX (11).  Source  and  destination  calculations 
in  the  Switch  Processing  module  use  these  values. 

XX(  10).  Equivalent  to  the  variable  PSRATE.  Contains 
the  packet  switching  rate  of  the  packet  switch. 

XX(  12).  Overhead  delay  of  the  ETS.  Considered  to  be 
jKJ  negligible  in  this  thesis,  but  available  for  future  use.  j 


Attributes 

Attribute  1 .  Contains  the  creation  time  of  an  entity 
representing  a  packet  entering  the  network. 

Attribute  2.  Equivalent  to  variable  DEST,  the 
destination  of  the  entity. 

Attribute  3«  Equivalent  to  variable  SRC,  the  source 
node  where  the  entity  was  created. 

Attribute  j4.  Equivalent  to  variable  LINK.  Derived 
from  SRC  or  DEST.  Identifies  the  channel  over  which  a 
packet  is  to  be  transmitted. 

Attribute  5.  Equivalent  to  variable  QUE.  Derived  from 
SRC  or  DEST.  Identifies  the  queue  in  which  a  packet  waits 
for  a  free  channel. 

Attribute  6.  Equivalent  to  variable  LENGTH.  Holds  the 
exponentially  determined  packet  length  used  in  the  trans¬ 
mission  delay  calculations  in  each  transmission  link. 

Attribute  7.  Equivalent  to  variable  RATE.  Holds  the 
transmission  rate  for  a  particular  packet  while  waiting  in  a 
FIFO  queue.  It  is  determined  in  the  user  written  function 
USERF ( 1 ) . 
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Appendix  2:  Full  Model  SLAM  I I  Network  Diagrams 


The  following  pages  of  Appendix  2  contains  the  SLAM  II 
network  diagrams  the  represent  the  full  model  of  the 
Heidelberg  backbone. 
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